With APZ turned on trying to scroll any scrollable list in Gaia apps results into a lot of white showing when panning. This can be viewed into the call log, the sms app or the contacts apps. Steps to reproduce: - If you have a Gaia without any data (calls, messages, contacts, ..), go into the gaia directory and do |make reference-workload-medium| - launch Gaia with APZ turned on - Open the dialer app, and switch to the call log (bottom left tab) - Wait for it to be loaded and starting panning to show the bottom of the list Expected result: - Smooth scrolling without any white ares Actual results: - occasionaly a white area is visible before it quickly refresh to show the scrolled content. Note: It seems easier to trigger by scrolling into one direction and then suddenly scroll the invert direction.

I made a rendertrace recording of scrolling around in the call history. Initial impressions are that painting seems to take too long, which is why we often end up in regions that haven't been painted yet. Tiling would probably help a lot here but we should be able to do better even without it. I'll investigate a bit more.

The dupe of this bug seems pretty bad - we can turn the gallery app completely black during scrolling.

is this similar to bug 943846 ?

The symptoms are similar, yeah. However this bug covers excessive "temporary" checkerboarding behavior. That bug included other root causes that would sometimes leave the content entirely blank and unrecoverable.

BenWa, thoughts?

I'll take a look next week. Meanwhile if someone can grab a performance profile of the gallery's main thread + the compositor thread, upload it and post the link here that'd be great.

Trying to figure out whether this is a blocker or not, the consensus is that if you can get this behavior without lifting the finger from the screen, then it's definitely 1.3+. Vivien, can you get it to happen without the "flick"?

Milan, I have gotten the settings to not move even though I scrolled down and then it will white out to the background. This is a pretty bad visually.

ie, I vote this to be a 1.3+

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #9) > Milan, I have gotten the settings to not move even though I scrolled down > and then it will white out to the background. This is a pretty bad visually. Can you post a video?

Given that apzc is landing on 1.3, we want to take this for 1.3+ blocking.

Note comment 8 - because this is asynchronous behaviour, we will always be in a position where we get the checkerboarding, we just want to define what is acceptable and what isn't. There is enough in this bug that is a blocker, but the "smooth scrolling without any white areas" is not a reasonable goal. I'll leave it as 1.3+ while we sort out what's what.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #11) > (In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from > comment #9) > > Milan, I have gotten the settings to not move even though I scrolled down > > and then it will white out to the background. This is a pretty bad visually. > > Can you post a video? Naoki, is it like the video in bug 958073?

By the way, bug 958073 shows up with and without APZC, so I just want to make sure we're not mixing different issues into the same bug. Naoki, when you ran into the "doesn't move at all", was it possible to do that with APZC off?

Note - during today's 1.4 testing, this is very easy to reproduce on marketplace by scrolling through search results.

hi milan: I believe it's an APZ issue. The settings scrolls fine when the APZ is turned off. When APZ is turned on, it might not move and later on white out. This is with 1.4 as well as 1.3 Gaia 22bc6be5b76cdc6d4e9667ff070979041a20ce2f Gecko http://hg.mozilla.org/releases/mozilla-aurora/rev/2c8f8683bd0d BuildID 20140109004002 Version 28.0a2 ro.build.version.incremental=eng.archermind.20131114.105818 ro.build.date=Thu Nov 14 10:58:33 CST 2013

Hi there. I don't know if the bug I am seeing is related but somehow the most simple html page consisting of only 33 lines of text is rendered black as soon as I scroll. My background-color is not black though. Here is the page: http://ffos.ddenis.info/renderbug1/ Video showing the issue: http://youtu.be/XmUOZh9rJBg

Disabling APZ makes the bug go away.

See bug 951259 comment 10 for a summary of the different issues. This bug tracks checkerboarding problems in gaia. (In reply to Denis Dzyubenko [:ddenis] from comment #19) > Hi there. I don't know if the bug I am seeing is related but somehow the > most simple html page consisting of only 33 lines of text is rendered black > as soon as I scroll. My background-color is not black though. > > Here is the page: http://ffos.ddenis.info/renderbug1/ > > Video showing the issue: http://youtu.be/XmUOZh9rJBg This looks more like we're running out of memory, and doesn't appear related to this bug (although the symptoms sound similar). Could you please file a new bug for this? It might be the same issue as bug 957925 but it might be something else so I don't want to mix them up just yet. (In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #9) > Milan, I have gotten the settings to not move even though I scrolled down > and then it will white out to the background. This is a pretty bad visually. I think the "not moving" part is something else. I will file a new bug for that. The "white out to the background" sounds like checkerboarding but I would need a video to make sure.

I filed bug 958549 for the settings app issue.

Attaching a video of the original issue reported by Vivien Nicolas with scrolling on the Contacts App (observed with AZPC enabled only). STR: Same as original steps (using |make reference-workload-medium|).

So considering that we only checkerboard under "reasonable" scenarios (i.e. flinging as fast as humanly possible, or reversing directions suddenly) and considering comment 13, I think we should move this to not block gaia-apzc any more, but mark it as follow-up work (i.e. blocking bug 949585). Any objections?

It's a bad UX for the end user; the panning various locations such as the marketplace and settings has a delay in the update of the screen when we encounter this bug and it then whites out the screen.

I also don't think we should really dig into checkerboarding problems until we've fixed bug 957668, as it will change a fair amount of this code. I'm unassigning this from BenWa because of this, and also because he's busy with other bugs at the moment.

PM triaged this bug and believes that it should be a blocker.

-> Milan, pending plan for this

This is a CS blocker. What other CS blockers in BenWa busy with?

Seems like the fix for this is involved and adds considerable risk to 1.3. We can consider pushing this to 1.4. Technically, this is a regression from 1.2 and is a must have feature for 1.4. Also, for 1.4, can we define the plan for Tiled Rendering (https://bugzilla.mozilla.org/show_bug.cgi?id=887819)

Moving to 1.3? per comment 32 to confirm agreement to move this to a 1.4 blocker.

This is an untested patch that I think may disallow checkerboarding. I may not get the chance to sort this out today, so leaving this here in case anyone wants to check it out. Otherwise will sort it out tomorrow (assuming it doesn't end up taking some silly amount of time).

Worth noting that using progressive rendering, unless the coherency check code is working correctly (it likely isn't), even if this patch does what I intend it to, you may still see checkerboarding.

Unfortunately this patch doesn't work :sadface: I'll fix it tomorrow morning.

The value returned by GetCurrentAsyncTransform itself needs to change.

Also, we should file separate bugs for these different approaches to parachute-knitting.

I grabbed a video + rendertrace of what I see when I try to reproduce this. Yes there is checkerboarding, but it's a very quick flash. It could be longer on some devices and depending on paint times/what else gecko is doing there but this video is representative of what I was able to reproduce after ~15 attempts. The rendertrace that I'll attach next corresponds to this video and shows the model of what's happening in more detail.

In the above trace, whenever the red rectangle (user-visible area) goes outside the green rectangle (painted content) is when there is checkerboarding. The yellow is what we have requested to be painted but has not yet been painted. The checkerboarding in question occurs at frames 131-152.

So drawing aborting would help here to plaster over the problems but there's a lot we can do first. Here's the first profile I collected: http://people.mozilla.org/~bgirard/cleopatra/#report=a3ab371e7a8663d3f94e61ed172b2b213684fa17 Several things look wrong here but I want to collect more data before we come to conclusions.

Profile with stacks (less accurate but used to pin-point the cause from the profile in comment 42).

QA Wanted to check the following: Can we have somebody take a look at the other applications, not just contacts, and tell us if the problems similar to 942750 show up elsewhere? We want to see if there is a Gaia level solution. In parallel, Nical was pointing me to bug https://bugzilla.mozilla.org/show_bug.cgi?id=942460, and perhaps that may help us with the bug above; it would be good if we can test that patch and see if it gives us the benefit we're looking for.

jsmith: I've done some of the initial legwork for the Email app in bug 965019. We also have checkerboarding in the email app.

(In reply to Jason Smith [:jsmith] from comment #45) > QA Wanted to check the following: > > Can we have somebody take a look at the other applications, not > just contacts, and tell us if the problems similar to 942750 show up > elsewhere? We want to see if there is a Gaia level solution. In > parallel, Nical was pointing me to bug > https://bugzilla.mozilla.org/show_bug.cgi?id=942460, and perhaps that > may help us with the bug above; it would be good if we can test that > patch and see if it gives us the benefit we're looking for. I have seen checkerboarding in the call log, sms, gallery and music mostly. Sometimes in contacts, settings and the email app.

Chris, given comment 32: > Seems like the fix for this is involved and adds considerable risk to 1.3. > We can consider pushing this to 1.4. Technically, this is a regression from > 1.2 and is a must have feature for 1.4. > > Also, for 1.4, can we define the plan for Tiled Rendering > (https://bugzilla.mozilla.org/show_bug.cgi?id=887819) What are your thoughts on punting this to 1.4?

Comment on attachment 8369516 [details] [diff] [review] WIP: Disallow checkerboarding when using APZC This has been obsoleted by the patches on bug 967502.

making it 1.3+

Can we get ETA to fix this bug? Thank you.

There is no ETA at this moment; there is no single "fix" for this bug, there are multiple approaches and mitigations as seen in the dependent bugs. Please contact Milan and myself for more details.

Going to clear the blocking flag here as this has inevitably turned into a meta bug.

One of the strategies we tried to improve checkerboarding perf was to expose different displayport heuristics and options in the gaia prefs and have QA evaluate them to see which worked best. Their results are on the etherpad at [1] but since I don't trust etherpad I'm copying out the relevant summary of results here for posterity. There are two groups of options; the options within a group are ranked in order of user experience (1 is the best). First group: _1_ APZ off: smooth no noticeable stutters or checkerboarding even in med/heavy loads _2_ APZ on, checkboarding off: contained stutters _3_ Default Options: has white checkerboarding, stutters, and feels jittery especially in heavy loads Second group: (results were most noticeable in MMS thread with lots of pictures, tie for 1st) _1_ build with APZC on and display heuristic select menu set to Default (white checkboarding, stutters, jittery) _1_ build with APZC on and display heuristic select menu set to Taller displayport (white checkboarding, more so with pictures, little bit of stuttering) _3_ build with APZC on and display heuristic select menu set to Faster paints (white checkerboarding, little bit of stuttering) _4_ build with APZC on and display heuristic select menu set to Assume perfect paints (some white checkboarding more when pictures are involved, litlle bit of stuttering) _5_ build with APZC on and display heuristic select menu set to Center displayport (lots of white checkboarding, stuttering when pictures are involved MMS) [1] https://etherpad.mozilla.org/APZ-v1-3

After some discussion with Timothy we realized that the results in comment 54 may have been obtained while async scrolling is in a "broken" state because of bug 965593 (see for instance bug 974081 for the sms app). So while the results above are technically valid for 1.3 *now* they do not represent what the user experience would be like if async scrolling weren't broken.

Bug 965593 has now been backed out, which should greatly improve the stutters/jittery behaviour that were noted in comment 54. It would good to have those tests re-done on a build that includes the backout as I suspect the results will be very different.

We need this patch for v1.3T.

Why is this needed for v1.3T? I don't think v1.3T uses APZC.

Uplifting this to 1.3 codebase would get most of Gecko and a large part of Gaia to 1.4 level. That is a serious request.

As Milan said, this would involve basically updating to 1.4, which would delay us by many weeks at least. Why is this needed?

(In reply to James Zhang from comment #60) > We need this patch for v1.3T. Hi James, APZC won't be enabled for v1.3T, it's not necessary. Thanks.

(In reply to Andreas Gal :gal from comment #63) > As Milan said, this would involve basically updating to 1.4, which would > delay us by many weeks at least. Why is this needed? Fabrics think we can't disable it on v1.3t, see bug 985928

I am counting 72 bugs that are implicated in this dependency tree. Cherry picking those would be a nightmare. And thats likely not all. I am sure we missed a few dependencies. This would add at least a month or two to the schedule trying to stabilize this. Its likely easier to abandon 1.3T and stabilize 1.4 for Tarako, but that would also add months of delays to the schedule. Steven, please do a coordination call to determine whether this bug is a blocker and if so, we should estimate a new schedule.

We are closing this meta bug as resolved fixed for 1.4. There are some app specific issues we are tracking as QC 1.4 CS blockers, and we have a correctness issue tracked in bug 984618, but this one can be closed.

SPRD disabled APZC for the evaluation.